r? @oli-obk

(rust-highfive has picked a reviewer for you, use r? to override)

Just encoding spans:
@bors try @rust-timer queue

Awaiting bors try build completion.

⌛ Trying commit 8a5ed78a766e6e1cba22b262cc54ef2999777801 with merge cd92c1a693aa7a1500ea987e9e722ccbf163b786...

☀️ Try build successful - checks-actions
Build commit: cd92c1a693aa7a1500ea987e9e722ccbf163b786 (cd92c1a693aa7a1500ea987e9e722ccbf163b786)

Queued cd92c1a693aa7a1500ea987e9e722ccbf163b786 with parent a2cd91c, future comparison URL.

@rustbot label: +S-waiting-on-perf

Finished benchmarking try commit (cd92c1a693aa7a1500ea987e9e722ccbf163b786): comparison url.

Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. Please note that if the perf results are neutral, you should likely undo the rollup=never given below by specifying rollup- to bors.

Importantly, though, if the results of this run are non-neutral do not roll this PR up -- it will mask other regressions or improvements in the roll up.

@bors rollup=never
@rustbot label: +S-waiting-on-review -S-waiting-on-perf

Perf is neutral.

Ok, so it's not the additional iteration of def ids or the additional query invocations, that's good to know at least. I guess now we need to find out which queries that you are caching this way cause the regression. Maybe add half of your commits, let's see if it has the regression. If it has, remove half the newly added commits and try again.. that should give us the culprit(s) fairly quickly

Spans were previously queried and encoded for all DefIds anyway, so this PR doesn't make much difference.
I'd rather be interested in seeing results for some (preferably expensive) query that was previously executed only for some small subset of DefIds.

Awaiting bors try build completion.

Just modifications to the queries.
@bors try @rust-timer queue

Awaiting bors try build completion.

⌛ Trying commit 596e4c803e7a0883ecccdbd3090239aceb4218af with merge d79a05ac22b5f71ab8f204dc69f27692d5d443f3...

☀️ Try build successful - checks-actions
Build commit: d79a05ac22b5f71ab8f204dc69f27692d5d443f3 (d79a05ac22b5f71ab8f204dc69f27692d5d443f3)

Queued d79a05ac22b5f71ab8f204dc69f27692d5d443f3 with parent 497c9a2, future comparison URL.

@rustbot label: +S-waiting-on-perf

Finished benchmarking try commit (d79a05ac22b5f71ab8f204dc69f27692d5d443f3): comparison url.

Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. Please note that if the perf results are neutral, you should likely undo the rollup=never given below by specifying rollup- to bors.

Importantly, though, if the results of this run are non-neutral do not roll this PR up -- it will mask other regressions or improvements in the roll up.

@bors rollup=never
@rustbot label: +S-waiting-on-review -S-waiting-on-perf

Iterator on non-MIR queries.
@bors try @rust-timer queue

Awaiting bors try build completion.

⌛ Trying commit d1b8abb8572c84855caa94d8088ad901006d064f with merge af7c9fb243263a146c0204f0c9673b6f8b2c7090...

@bors r=oli-obk

📌 Commit 97ee7c7 has been approved by oli-obk

⌛ Testing commit 97ee7c7 with merge 6ac46f1e51db8999af302e7ecf99c54ed82f4505...

💔 Test failed - checks-actions

A job failed! Check out the build log: (web) (plain)

Prepare workflow directory
Prepare all required actions
Getting action download info
Download action repository 'actions/checkout@v2'
##[warning]Failed to download action 'https://api.github.com/repos/actions/checkout/zipball/5a4ac9002d0be2fb38bd78e4b4dbde5606d7042f'. Error: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond.
##[warning]Back off 10.814 seconds before retry.
##[warning]Failed to download action 'https://api.github.com/repos/actions/checkout/zipball/5a4ac9002d0be2fb38bd78e4b4dbde5606d7042f'. Error: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond.
##[warning]Back off 14.118 seconds before retry.
##[error]A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond.

Spurious failure.
@bors retry

⌛ Testing commit 97ee7c7 with merge 85e355e...

☀️ Test successful - checks-actions
Approved by: oli-obk
Pushing 85e355e to master...

@cjgillot @oli-obk It seems there was some perf regressions due to this pull request as you can see here that already were present in the one of the perf runs above. Any thoughts on this regressions and if we need to look into addressing them?

We're now encoding more things in metadata and thus also causing more query invocations. We need to do a general analysis to find out what needs to go into metadata and what not. This is work we need do independently of this PR. Until then... maybe we can figure out what caused this specific regression in def_span runs and try to exclude these from being done?

@oli-obk I think it would also be acceptable to wait on addressing the issue until it can be looked at holistically, but I'd just be worried that it will never get looked at. If you think adding an issue to look into this a later point will actually lead to the issue being addressed, I'm fine with that.